Implications of the recent COSE industry announcement on System V.4 =================================================================== Two appoaches to Unix based standards _____________________________________ Over the last couple of years a number of participants within the Unix(TM) Industry have attempted to define Unix based standards in terms of a particular IMPLEMENTATION of the operating system, such as System V.4 (eg. USL) and OSF/1 (eg. DEC). "Implementation" meaning the actual SOURCE code of the kernel. Other vendors, including HP, have continued to support the definition of Unix based standards in terms of Application Programming Interfaces (API). As a consequence HP has aggressively implemented key standards based API definitions such as XPG/4, SVID 2 and OSF's AES into HPUX and was already planning SVID 3 Level 1 compliance in 1994 (the API definition for System V.4). The benefits and flaws of each approach _______________________________________ The advantage of the "API based" standards approach is that each vendor can optimise performance and provide additional functionality (eg. High Availability) WITHOUT sacrificing application portability, as long as a single, common set of APIs exists. However, until recently, this approach was flawed because of the existence of multiple API standards with individual vendors offering different subsets of these APIs. In practice, this inhibited portability. Proponents of the "implementation based" standards approach believed that the way to solve the portability issue was to demand that all vendors used one source code implementation (and therefore one API). However this approach had many flaws. Innovation in performance and functionality, available in the "API" approach, was severely limited by the "implementation based" strategy. Ownership of the source code by a single vendor provided the threat of industry dominance which can ultimately harm customers' interests. Worse still, the portability goal was unachievable because there were MULTIPLE, competing implementations (eg V.4, OSF/1), each with their own API set. Users and developers forced to "bet" ____________________________________ In this confused environment, both software developers and customers were required to make two "bets". First, should they support the "implementation" or "API" approach to Unix standards in their own requirements specifications? Second, having chosen the approach, which "standard" should they choose? (eg. "V.4 vs OSF/1" or "XPG/4 vs AES vs SVID"). Industry resolution of the portability problem ______________________________________________ With the recent 1st September COSE announcement, an overwhelming majority of industry participants, including software developers and customer representatives, resolved this issue. The direction chosen is the "API based" approach and agreement has been reached on the SINGLE, Common OS API set which will finally offer true, industry-wide portability. Ownership of this Common OS API set will be with X/Open, preventing single vendor dominance. The standard will succeed where previous API standards have failed by providing a set of APIs that has been tested against 50 real life applications, offering meaningful "completeness". Furthermore, with the support of almost all major industry participants, the standard will become pervasive. Portability will be achieved whilst protecting the innovation available from an "API based" approach to Unix based standards. The implications for System V.4 _______________________________ Novell/USL's strong participation in this COSE process and support for X/Open's control of the "API based" standards approach has effectively signalled the end to USL's previous policy of driving for an "implementation based" approach, centred on System V.4. In effect System V.4 has become IRRELEVANT as a Unix based standard. The implication for end users and software developers alike is that they should start to withdraw System V.4 from their requirement specifications and start replacing it with the API specifications that will eventually become XPG4+ (ie the Common OS API set based on a superset of XPG4, AES and SVID3 Level 1). Furthermore, customers and software partners should recognise that maintaining a commitment to System V.4 as a requirement specification may actually lead them down a path that moves AWAY from industry-wide compatability and DENIES them the benefits available from functionality and performance innovations that will be delivered by the rest of the Unix industry. Hewlett-Packard: The Open Systems Trusted Advisor _________________________________________________ After leading the COSE efforts towards the unification of Unix and having our support for an "API based" approach to industry standards substantiated, Hewlett-Packard is in a strong position to support software developers and end users in their move towards the new XPG4+ standards environment. HP continues to demonstrate its leadership position as the Open Systems Trusted Advisor.